REMARKS 

Claims 1-4, and 6-19 are pending. 

Claim 5 is cancelled. 

Claims 14-19 are new. 

Claims 1, 4, and 10-12 are amended. 

Claims 11-13 are rejected under 35 USC 102(b). 

Claims 1-4 and 6-10 are rejected under 35 USC 103(a). 

The rejections are traversed. 

Claim Amendments 
Claims 1, 4, and 10-12 are amended. Claims 14-19 are new. Support for the 
amendments may be found in the application as filed, for example, on pages 5-7, and 11-14, and 
FIGS. 3-4. No new matter has been added. 

Claim rejections under 35 USC §102 

Claims 1 1-13 are rejected under 35 USC 102(b) as being anticipated by Andrew S. 
Tanenbaum, "Computer Networks", Third Edition, 1996 (hereinafter Tanenbaum). 

As amended, claim 1 1 includes "analyzing a set of parameters in an incoming data 
packet, wherein the set of parameters analyzed depends upon a type of service access point from 
which the data packet came." Accordingly, the parameters that are analyzed are parameters of 
the data packet. 

The Examiner cited the quality of service parameters of Tanenbaum for analyzing the set 
of parameters. However, each of the enumerated parameters is related to the transport of a 
packet, not parameters in the packet itself. For example, "Connection establishment delay" and 
"Transit delay" relate to times taken in transporting a packet. In another example, "Connection 
establishment failure probability" and "Resilience" relate to probabilities of failures or 
terminations of connections. Other parameters indicate the protection implemented by the 
transport layer (Protection), the amount of data transmitted (Throughput), number of lost or 
garbled messaged (Residual error ratio), and the importance of a connection (Priority). Although 
each of these parameters relate to characteristics of a connection formed by data packets, there is 
no suggestion that the parameters analyzed are the parameters in a data packet. 
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Furthermore, as recited in claim 1 1, "the set of parameters analyzed depends upon a type 
of service access point from which the data packet came." In the rejection of claim 1 1, it is 
unclear what the Examiner is citing for the service access point. In other rejections, the 
Examiner is using a TCP socket as a service access point. See Office Action June 1, 2007, p. 4. 
No mention is made of a set of parameters depending on the particular TCP socket. 

Accordingly, Tanenbaum does not teach each and every element of claim 1 1 and 
dependent claims 12-13. The Applicant respectfully requests that the Examiner withdraw the 
rejection of claims 11-13. 

Claim 12 includes "analyzing the data packet according to a plurality of sets of 
parameters, each set of parameters including a priority; wherein the sets of parameters are used 
in analyzing the data packet in order of priority." Accordingly, each set of parameters includes a 
priority. That priority is used to determine the order the sets are used in analyzing the data 
packet. 

Tanenbaum does mention priority. However, the priority is the priority for servicing 
connections so that higher priority connections are services before lower priority connections. 
Tanenbaum, p. 483. At best, the priority in Tanenbaum indicates an order in which data packets 
from different connections are processed. It does not relate to multiple analyses of a single data 
packet in order of priority. 

Accordingly, Tanenbaum does not teach each and every element of claim 12. The 
Applicant respectfully requests that the Examiner withdraw the rejection of claim 12. 

Claim rejections under 35 USC §103 

Claims 1-4 are rejected under 35 USC 103(a) as being unpatentable over Tanenbaum in 
view of Raphaeli ct al. (U.S. Pub. No. 20030103521). 

A. Claim I 

As amended, claim 1 includes "classifying the application data as internet protocol (IP) 
based or non-IP based according to the associated service access point." 

The Examiner has cited a TCP socket as a service access point. Tanenbaum does 
describe a neutral term "Transport Service Access Point" to describe both IP address + local port 
pairs and AAE-SAPs in ATM networks. Tanenbaum, p. 489, Since ATM may or may not be 
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used with IP, an ATM SAP may or may not IP based. See Tannenbaum, p. 449. Even though 
service access points are described as IP and non-IP based, there is no mention of a classification 
based on this distinction. 

Claim 1 also includes "determining if a connection exists for the application data in 
response to the classi fication of the application data.'* Thus, the classification of IP or non-IP 
based is used to determine if a connection exists. 

The Examiner cited a SOCKET call as determining if a connection exists, where a failure 
to create a socket indicates that one exists. However, Tanenbaum does not describe making this 
determination in response to a classification of the application data as IP or non-IP based. 

Moreover, the SOCKET call is the first thing a process must do for network I/O. 
Stevens, p. 267 (cited in rejection of other claims for details on Berkeley sockets.) As a result, 
the SOCKET call cannot be the determination if the connection exists. For example, in claim 1, 
the application data was classified according to the service access point through which it was 
received. If the socket was the service access point and data was received through it, it must 
have been created already. There is no suggestion to make another SOCKET call to create the 
socket after application data was received through it. 

The addition of Raphael i does not cure the deficiencies of Tanenbaum. Raphaeli is 
directed towards a media access control (MAC) protocol that is intended for use over noisy 
shared media channels. Raphaeli, Abstract. A MAC layer is a sublayer of the data link layer. 
Tanenbaum, p. 243. Referring to Figs. 1-18 and 1-19 of Tanenbaum, it can be seen that the IP 
layer is higher than the data link layer and hence the MAC layer. Accordingly, a MAC layer 
does not depend on the IP layer, thus, any analysis of the MAC layer does not reveal whether the 
data is IP based. Moreover, there is no mention of IP in Raphaeli. As a result, Raphaeli does not 
suggest classifying or determining if a connection exists based on a classification of IP or non-IP. 

Accordingly, the combination of Tanenbaum and Raphaeli does not teach or suggest each 
and every element of claim 1 . The Applicant respectfully requests that the Examiner withdraw 
the rejection of claim 1 and dependent claims 2-4. 

B. Claim 4 

Claim 4 recites that "the power line communication system is connection-oriented." In 
addition, claim 4 recites that "receiving application data further comprises: receiving 
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connectionless application data from the application; and mapping the connectionless application 
data into transport data for a power line communication system connection." Thus, 
connectionless application data is mapped into transport data of a connection of the connection- 
oriented power line communication system. 

In contrast, as described in the cited section of Tanenbaum, at the transport layer or the 
network layer, the connection is either connection-oriented or connectionless. Tanenbaum, p. 
480. However, no mention is made of the connection orientation of the application data 
presented to the transport layer. Accordingly, the combination of Tanenbaum and Raphaeli does 
not teach or suggest each and every element of claim 4. The Applicant respectfully requests that 
the Examiner withdraw the rejection of claim 4. 

C. New Claims 14-19 

Claim 14 recites "accessing a classification table for a mapping of the service access ! 
point to a connection identifier; and providing a connection associated with the connection 
identifier as the connection." Accordingly, a classification table contains a mapping of service 
access points to connection identifiers. 

In Tanenbaum, a SOCKET call returns a file descriptor. Tanenbaum, p. 487. Although 
this file descriptor can be used in subsequent SEND and RECEIVE calls, the use of it does not 
describe a classification table mapping the service access point to a connection identifier. 

Claim 15 recites "accessing a classification table for a mapping of the service access 
point and at least one of an IP address, a port number, and a type of service field to the 
connection identifier; and providing a connection associated with the connection identifier as the 
connection." Accordingly , the association in the classification table of connection identifiers is 
based on the service access point and additional data. Claim 16 includes "accessing the 
classification table for a mapping of the service access point, an IP address, and a port number to 
the connection identifier." 

In contrast, in Tanenbaum, the transport service access point (TSAP) is described with 
reference to the Internet as an IP address and a local port. In other words, the IP address and the 
local port are the service access point. Tanenbaum, p. 489. Accordingly, a service access point 
that is distinct from an IP address, a port number, or a type of service field, and is associated in a 
classification table is not described in Tanenbaum. 

I 
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Claim 17 includes "comparing the application data with at least one classifier rule for a 
match; and providing a connection associated with a matching classifier rule as the connection." 
Claim 18 recites "comparing the application data only with classifier rules associated with the 
service access point." 

The Examiner cited the protocol argument of a socket call of Stevens as a rule. However, 
the argument of the socket call merely describes what type of socket is desired. Stevens, p. 267. 
Neither Tanenbaum, nor Stevens describes a comparison of application data to an argument of 
the socket call. 

The Examiner also cited the "Leaky Bucket Algorithm" in reference to a rule. However, 
the Leaky Bucket Algorithm is not described as being associated with a connection to be used as 
the connection for the application data. Rather, the Leaky Bucket Algorithm has decisions such 
as: "If there is room in the queue, add, otherwise, discard; and every clock tick, transmit a 
packet." Tanenbaum, p. 381 . The comparison of a packet to room left in the queue does not 
result in a connection. 

Furthermore, there is no mention of whether the Leaky Bucket Algorithm is based on 
connections. The algorithm is in the Network Layer section of Tanenbaum. IP is one example 
of a layer equivalent to the network layer. However, IP is connectionless. Thus, there would be 
no association of the Leaky Bucket Algorithm to a connection if it was implemented for IP 
packets. 

Claim 19 recites "for application data that is audio/visual application data comparing the 
application data to only at least one destination address within the at least one classifier rule." 
First, none of the cited references specifically references audio/visual application data. Second, 
no rule described where the application data is only compared with a destination address. 

Accordingly, new claims 14-19 are not taught or suggested by the combination of 
Tanenbaum, Stevens, and Raphaeli. 

a Claim 6 

Claims 6-10 are rejected under 35 USC 103(a) as being unpatetnable over Andrew in 
view of W. Richards Stevens, "UNIX Network Programming", 1990, hereinafter Stevens. 

Claim 6 recites "classifying the data packet according to the service access point and at 
least one rule, causing the packet to be associated with a connection." 



Docket No. 8371-156 



Page 10 of 12 



Application No. 10/663,866 



As described above, the Examiner cited the socket and parameters used in creating the 
socket as the service access point and a rule for classifying data packets. However, the socket 
call is for creating a socket. By the point of the socket call, the socket has not been created, thus, 
no data packets could have been received through the socket as the service access point. As 
described above, a new socket call would not be made if data was just received through the 
socket. 

Furthermore, Tanenbaum describes a service access point as having an address that 
uniquely identifies it. Tanenbaum, p. 22. Newly created sockets do not have address. The 
address is assigned by the BIND primitive or the CONNECT primitive. Tanenbaum, p. 487. 
Accordingly, the service access point is created when an address is associated in the BIND or 
CONNECT primitive. As a result, the parameters used in creating a socket are part of a service 
access point. Thus, something else must be used as the rule in the classification of the data in 
claim 6. 

Accordingly, the combination of Tanenbaum and Stevens does not teach or suggest each 
and every element of claim 6 and dependent claims 7-10. The Applicant respectfully requests 
that the Examiner withdraw the rejection of claims 6-10. 

K Claim 10 

Claim 1 0 recites that "classifying the data packet further comprising analyzing a set of 
parameters in the data packet to determine if the parameters match those of a rale, and if the 
parameters do match, associating the data packet with a connection identified by a connection 
identifier in the rule." 

The Examiner cited the "Leaky Bucket Algorithm" as the rule. As described above, the 
Leaky Bucket Algorithm does not result in a connection identified by the rule. Accordingly, the 
combination of Tanenbaum and Stevens does not teach or suggest each and every element of 
claim 10. The Applicant respectfully requests that the Examiner withdraw the rejection of claim 
10. 
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Conclusion 

For the foregoing reasons, reconsideration and allowance of claims 1-4, and 6-19 of the 
application as amended is requested. The Examiner is encouraged to telephone the undersigned 
at (503) 222-361 3 if it appears that an interview would be helpful in advancing the case. 



MARGER JOHNSON & McCOLLOM, P.O. 
210 S W Morrison Street, Suite 400 
Portland, OR 97204 
503-222-3613 



Customer No. 46404 
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Respectfully submitted, 



MARGER JOHNSON & McCOLLOM, P.C. 




Derek Meeker 
Reg. No. 53,313 



